A functional blueprint of an application may define the topology (e.g., the number of tiers), configuration, actions, constraints, operating systems, and software packages that need to be provisioned to deploy an application or server. A deployment blueprint for each functional blueprint defines a way (amongst many) in which the application could be provisioned in terms of mapping to resource sets and the required compute, storage, network. For example, a “QA” deployment blueprint may use a single resource set with one virtual machine (VM) to host all three tiers of application, whereas a “Production” deployment blueprint may distribute the three individual application tiers to three different resource sets.
Currently, there exist a number of different conventional methods to generate functional blueprints or deployment blueprints. However, the conventional methods provide a blueprint that is monolithic in design, for example, an application template that includes the definition of all the functional components and their respective software stacks in situ. As a result, the conventional blueprint may be unsuitable for extensive re-use. For example, there may be a number of different choices of software stack elements in a software stack. With the current monolithic design, this would mean creating multiple functional blueprints for all the different options. The sheer choice of re-usable services, similar conformant infrastructure, software stack elements, and/or versions may lead to an explosion in the number of complete blueprints to be defined and maintained in a catalog. As a result, managing the conventional blueprints may be unworkable, or cumbersome at best.